Yes, it’s me again with this DSA-1571 exploitation issue. The discovery, explanation and exploitation of the bug is now part of my final coursework for my postgraduate degree career. So, yes… sorry. Some weeks ago I started suspecting about the attack to PFS in SSL with EDH. The key point is: the key space is dependent of the PRNG state. The bug affects the initialization of the PRNG, but the random string has not a pattern by it self. If you ask for many random numbers to the PRNG, you gonna get numbers that differ among them, since they are the output of a hash function of them self. So each random number depends on, besides the PID, the state of the PRNG pool in the moment (in other words, amount of bytes that you already pull from the PRNG pool before) The explained attack was based in a fixed list of private exponents (which are selected randomly during the DHE handshake), presupposing that all the application call RAND_bytes() the same number of times before get it. To make the list of exponent I ran the openssl s_client with all the possible PIDs, hoping that all the applications behaves the same way. After more tests I notice that that was an overgeneralization. The proof is in the pudding: wget and cURL, two simple CLI file retrievers, gets different exponent between them, even running with the same PID. I was working on this when I accidentally found a really nice Eric Rescorla’s post which is deeply related with this. The post goes further and analyzes the interaction between how Apache forks off and how it generates SSL handshakes. So, I made lists of secret exponents for wget, curl, openssl s_client and openssl s_server with a modification version of libssl (appling this patch) and running scripts like this:

for i in $(seq $((2**15)));
do
  export MAGICPID=$i;
  LD_LIBRARY_PATH="openssl.broken/" LD_PRELOAD="./getpid.so" \
     wget --no-check-certificate https://localhost/ -q  -O /dev/null ;
  echo $i ;
done

As you can see, I used the HD Moore’s GetPID faker shared library and a normal local Apache with mod_ssl. The broken libssl (which is in .openssl.broken/) store up in /tmp/data.key a csv with command name, PID and all the DH components (g, x, y and p). But this way is farly unconfortable for others SSL deamon servers. Have you got any better idea?

Maybe the LHC is robing the planet of angular momentum. Maybe having played with quantum gravity has unpredictable consequences. Who cares the reason, it’s my dream becoming true. And you, haven’t got any plans for the extra day in October yet? Luckily it’s weekend.

What I liked

• Excellent organization, orga team fully deserved all the praise they got.
• Meeting people - it was the first DebConf I attended in person, so it was a pleasure to meet lots of folks whom I’ve only known online before.
• Quite a few interesting talks (videos are available, or will be available shortly, in DebConf8 video archive). Particularly recommended: quality assurance talks/BOFs by Lucas Nussbaum, BTS development progress by Don Armstrong, method diffusion in large volunteer projects by Martin Krafft, talk and debate on OpenSSL security issue by Luciano Bello, various lightning talks.
• Deserving a special mention, a talk by Mark Shuttleworth on Debian and Ubuntu relationship. I thought that he said all the right words and, judging by reactions, attitude towards Ubuntu has changed significantly during the last year, turning from hostility to peaceful cooperation.
• Argentinian food: steaks, empanadas, alfajores.

What I did not like

• People pay much less attention to fixing RC bugs than they used to, the two BSPs organized during DebConf8 attracted only 3-5 people.
• Some nice ideas being thrown around without anyone volunteering to work on them. Not really surprising, given that most of the core teams are short on manpower.
• Almost complete lack of events targeted at engaging users and beginner contributors.
• Quite a few specialized talks, interesting (IMHO) to only a minor percentage of the attendees.
• Lots of discussions with few or no specific decisions or action items.
• Pretty long trips to and from Mar del Plata (about 30 hours door-to-door travel time for me), luggage was lost for 2 days on the way there.

What I did

• Attended about 75% of talks, tried to contribute to discussion in constructive, non-flamy ways .
• Participated in BSPs, contributed debugging information, patches or fixes for about a dozen of release critical bugs, started triaging sparc-specific bugs.
• Started working on updating the Debian kernel handbook for Lenny, about 1/3 done.
• Gave a “Google and Open Source” lightning talk.

I've had an outstandingly good time, as expected. Much kudos to the local team here in Argentina for organising the conference so well, and it's great to see that the efforts of the video team are making it possible for lots of people to attend the talks virtually as well. Good work, folks! My highlights so far:

• Getting all the right people together in one room for a really productive session discussing "tdebs", a new way of organising the translations in our packages. In less than an hour, we went from a mix of opinions and suggestions (all with problems) to a good consensus about what we're going to do and what work needs to be done. In Debian we work very effectively online normally, but this kind of design discussion could easily have taken a month or more via email. Sometimes face-to-face meetings just work better! (See the wiki for the session notes.)
• The 15th Birthday Party last night. I got to formally accept our "epic fail" award from Luciano Bello after his recent trip to Las Vegas to tell the Defcon and Blackhat folks about our recent OpenSSL problems. Then I was coerced into dancing for the delight of the crowd. Apparently some git even caught that on video. Oh, the shame...
• Beeeeeeeeef! I joined a group of people at the "Palacio del Bife" restaurant in the centre of town on Monday night, and we ate a lot of beef. I had a massive T-bone steak which was awesome - large and very very nicely cooked. I'll have to go again. *grin*

Unfortunately, the end of the week is quickly approaching. I'll have to head back to England all too soon.

Finally, this alternative speaker became an speaker, nothing more. Maxi and I will be given a lecture during Black Hat, as you can see here.

Just think about being in the same rostrum than Fyodor makes me feel so small...

Finally the pwnie award nominations are out, a bit late though.

Of course we also got our nomination for the infamous openssl issue in the Most Epic FAIL category as well as one nomination for Luciano for the discovery of this in the Mass0wnage section :/

I nominated Wonderware (I wrote about that before) in the Lamest vendor response category, looks like it has been accepted.

wordpress also got its place in the Mass0wnage category:

An unbelievable number of WordPress vulnerabilities (CVE-2008-*)

Discovered by: everybody who cared to look

It seems like hardly a week goes by without a new vulnerability in WordPress or one of its many plugins. Many of them are actively being exploited to own popular WordPress blogs and use them to serve spam or client-side exploits to unsuspecting visitors. The popularity of WordPress combined with the abysmal security practices of WordPress plugin developers places the entire Internet at risk and is worty of a nomination.

138 reported vulnerabilities since 2004 referring to MITRE, shocking!

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The client makes Y_c public by sending it to the server.
  
• The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this shared secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch for Wireshark 1.0.2 can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decipher with stop itself.
  
• The brute force attack should run in a background process (and with a progress bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next tittle):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The clients makes Y_c public by sending it to the server.
  
• The share secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this share secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematicaly secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the share secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, If you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decypher with stop itselft.
  
• The brute force attack should run in a background process (and with a progression bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

The last weeks have been very active. A lot of e-mails from people and magazines, a lot of congratulations and a lot of free beer made me feel like a rock star :) Thanks a lot to everyone. I really appreciated that.

And maybe this petition would sound you like an abuse of this situation. And maybe you are right.

The fact is, I need an sponsor to travel to Defcon16, in Las Vegas, the next August. I need a flight ticket, 3 or 4 nights in a hotel and 2 meals per day.

I've been accepted to explain the Debian/OpenSSL problem and I'm dying to be there. If you work for a company which is looking for a nice way to say "thank you", please consider this option :)

Contact me at luciano <alt+64> debian.org for more details. Thanks.

update (13 minutes later): I just received confirmation from the Black Hat organization to be an alternative speaker there too! So I will need to fund 5 extra nights... :D

The recent OpenSSL incident can not be hidden. It was a very important blow to the Debian project's public face and reputation. A major hole slipped under the door in the form of a bugfix - and with all the good intention. This was not a deliberate attack, nor was it the result of a bad or sloppy maintainer - It was a honest, although painful, human mistake.
Several people started laughing at our processes and supposed strengths right away. I do, however, feel this shows how Debian is stronger security-wise than any other system. And it also shows how this saying, with enough eyeballs, all bugs are shallow, not only didn't lose validity, but was reaffirmed. Free Software development was also proved to be better than security through obscurity again.
Why?
Because were it not because of OpenSSL (and in this case in particular, Debian's packaging) being Free and subject to a code audit, this problem would have never been found. I have been asking to some friends who are part of different black-hat groups, and looking for this kind of information on the Web, it seems that -were it not for Luciano's work, we would still be running cryptographically weakened versions of OpenSSL for a long time. After all, 32768 possible keys is still quite a lot for a black-hat group to find as uneven noise, as a lead to showing the undeniable weakness.
It took two years to find the bug, yes. But it was found doing quality assurance work on publicly available source code. It was promptly fixed, mitigating (as far as possible) as much damage as could be caused. Tools for finding and fixing the defective keys were crafted and freed together with the announcement. Yes, there will be some compromises due to this, I'm sure, but an embarassing hole has been dealt with in the best way possible.
Anyway... I am very happy - I was going over Luciano's NM report, and found something I only suspected but was not sure about. I can now state clearly: I have never been so happy to advocate somebody to become a DD.
Luciano wrote a very good blog post (in Spanish) with his viewpoints on the Debian OpenSSL incident. If you happen to understand Spanish and are reading this blog, please drop over Luciano's.
Luciano: Once again, my hat goes off for you :-)

Whoa, this security bug exposed by Luciano Bello (Ola!) is one of the worst I’ve ever seen. Time to regenerate your key with the updated openssl 0.9.8c packages. This seems to be Debian specific patch that caused this bug. Further instructions should be posted on a special Debian key rollover page and the Debian wiki. Update: key rollover is hard. :/ ssh-vulnkey was missing for awhile and only recent updates to openssh-server seem to regenerate the keys for me.

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It s hard, but it s necessary.

In my free Friday I made a little cuasi-web knocking for OpenBSD s Packet Filter. Click here if you want to read more.

Many years ago I heard that the Debian logo represents a galaxy. And I always thought There is no galaxy that looks like that . Of course, I was wrong.

The Astronomy Picture of the Day from few days ago is a really nice picture of the Messier 74 galaxy.

Any resemblance is purely coincidental :)

Better than just a party, it s a bug squashing party! Imagemagick needs your help. It a very important package for Debian and its really outdated. It has more than 100 bugs.


The objective, is to reduce the bugs to less than 20 in a month in the current development version. Let s go for them! :)

Luciano, you might be interested in how even good captchas can be processed automatically: just present them via some trojan to masses of unsuspecting users.

Some months ago, I commented about a weak implementation in a fancy captcha. Today I would like to comment about other bad implementations, but in other ways.
The goodA captcha should have big Shannon entropy, finite, but big. The session ID and the challenge must not be reused. The images must be resistant to OCR but should be understandable by a human.
The badHere is the first example:

Believe it or not.. This is a real case. So incredible eh?

The uglyThe victim, in this case, is this one:
This is an implementation of captchanumbers, by Hadar Porat. This captcha and many others generated by captchanumbers can be read with this script.

The idea is simple. As the numbers are nearly in the same place, they can be cut. Those parts can compared independently, reducing the entropy. May be the script and this image would be more enlightening than my limited English:

The 10,000 possibilities was reduced to 159. No OCR, 100% deterministic.

Second moral: Understand the fundamentals first, write code later.

In Spanish, occurrence and stupid idea are the same word.
j= w3m planet.debian.org -dump -no-graph -l 200 tr -d -C [:alpha:] tr [:upper:] [:lower:] ; for i in seq $ #j ; do echo $j cut -b $i; done sort uniq -c while read w; do y= echo $w cut -f 1 -d ' ' ; echo -n $(echo "scale=5; $y/$ #j " bc); echo " echo $w cut -f 2 -d ' ' " ;done sort -rn

After a long long long process of 946 days, I m a Debian Developer :-).

Let s have a drink... today it s on me.

yes w3m -M -F -dump http://nm.debian.org/nmlist.php 2> /dev/null grep -A 60 "Luciano Bello" > /tmp/DAM- date +%F .txt ; ! diff /tmp/DAM- date -d yesterday +%F .txt /tmp/DAM- date +%F .txt > /dev/null && echo "Eppur si muove"

Thanks and continue like this. Go for them^W us :)